This size could be wrong around the time that the batch fills up if another thread flushes first. Is that intentional, like a best effort?

Good question -- this implementation means that if you try to push a lot of spans through simultaneously with multiple threads, exports may contain batches of somewhat more or fewer than the max_batch_size number of spans. I figure this is okay at this stage of development.

But we may end up wanting to do something like: lock, append the span, test for length, generate something like a flush request, then release the lock. This is a fair amount of complexity though, which I'm trying to avoid. I'm hoping we can arrive at a solution that's maximally simple (suggestions always welcome).

I have updated the Accumulator to do batching, so we should have uniform batch sizes now.

Not sure how we'd do it, but this still has the issue that there is no way to interrupt the exporter if it is in a backoff loop.

Yeah, we should figure out how we want this to behave. I'm thinking the sleep during backoff should be interruptible (which can be done with an Event object), but the actual sending should not be (within some reasonable timeout).